NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2653

Internet Message Format | 1996-08-05 | 13.9 KB

Path: grafix.xs4all.nl!john.hendrikx
Date: Fri, 02 Feb 96 20:55:54 GMT+1
Newsgroups: comp.sys.amiga.programmer
Distribution: world
Subject: Re: Amiga doesn`t need Planar!
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
From: [e-mail] (John Hendrikx)
Message-ID: <[e-mail]>
Organization: Grafix Attack BBS Holland

In a message of 31 Jan 96 Juergen "rally" Fischer wrote to All:

 >>  TlM> Planar rules, its far more flexible, you don`t need 256 colours
 >> worth
 >>  TlM> of bitmap memory for a 2 color screen, etc. i.e you just use 2
 >> Colours

 >> Tell me, how much gfx-memory-accesses does it take to draw a simple 100
 >> pixel vertical line on a 7-bit Planar display?

 JrF> worst case example ;)

Yes, but if lines have 'random' angles then you'll find that 50% of these could
be considered 'vertical' (ie, only 1 pixel per row).  Then 25% of the remaining
50% of possible line angles has to plot 1 or 2 pixels per row (again very bad).
 Only a very small portion of lines (ie, the near horizontal ones) drawn are
-nearly- as fast as they would be in Chunky (at same depth).

 >> Another example;

 >> You have a 12-bit planar screen, and you want to blit an object of 40x40
 >> pixels

 >> You have a 16-bit Chunky screen (ie, again better quality) and you want
 >> to blit

 JrF> True, for small BOBs the planar overhead is bigger. BTW edges of 16bit
 JrF> objs also need special handling, i.e. switching from LONG to WORD write
 JrF> at edges.

Yes, true, but I assumed pixels would be plotted one WORD at the time.
Plotting LONGs were possible would be a possible optimisation which I didn't
even take into acount.

 JrF> But when it comes up to larger BOBs, 12bit should become faster in
 JrF> most cases.

The bob would have to be pretty large before it is faster, I'd say it would
have to be more than 100 pixels wide before this happens, and well, games seem
to favour smaller bobs (especially the ones running on LoRes).

 JrF> "Not writing the zeros" on chunky display is not always faster,
 JrF> example is chunky mapping to fastmem on 020/030. Of course special
 JrF> hardware can handle this, we also assume special hardware on planar
 JrF> (bitblitter), without it you can't get all horiz positions for BOBs
 JrF> without a megacpu.

Yes, I was assuming blitter hardware here, which can check for zero to see
whether the destination should be modified or not.  This makes masking really
fast and easy as no seperate mask is needed.  Planar hardware would have to do
extra reads to get the mask.

 JrF> Well, a trick that chunky can't do is for example only copying 6
 JrF> planes, and zero storing to the rest of the 6 planes, saves you 6
 JrF> planes reading. Gives you 64 colors out of the 2^12.

It is of little use though :-(

 JrF> it all depends, and for 2D games planar was and still is an advantage.

I'm not so sure, lots of cool effects can be done with Chunky even for 2d
games.

 >>  TlM> Amiga Rules... Custom Chips Rule..

 >> (My?) definition of Amiga:  Anything which runs *REAL* Amiga software
 >> like DirOpus, AdPro, Final Writer, WorkBench, AmigaShell, etcetera...

 JrF> Allthough having not such extreme opinions, I fully agree with the 2
 JrF> statements.

 JrF> Amiga rules: no comment nessesary ;) ... well, the interesting thing
 JrF> is that if you look at the OS, there are things where the term "Only
 JrF> Amiga makes it possible" is just true and not fanatism. And when I see
 JrF> 50Hz virtual screen and 50Hz mousepointer, then I can say that AGA got
 JrF> at least some goodies seen on no other "superior" hardware.

50Hz Mouse pointer is no problem on modern gfx-cards, they've got a special
sprite for that.  The problem is Windows.

 JrF> Custom Chips rule: Well I gave already the mousepointer example, and
 JrF> immedeately got to admit you got not much fun if you direct it over a
 JrF> flickering dbl screen because no more bandwidth. BUT: I don't see AGA
 JrF> as something you got to compare with the newest S3 chipset (thinking
 JrF> about wb screens here). Just run WB on a gfxcard to compare, or put out
 JrF> the gfx-card of the clone to compare ;)

Do you know what I dislike most about Amiga?  The fact that a MAC Emulator can
run all MAC software on my Amiga, but my Amiga can't run all Amiga software.
Maybe we should fix that problem first?  Maybe we should write an Amiga
emulator FOR Amiga so we can run all our Amiga software?

 JrF> But when it comes to games, I say: AGA is still very usable today.

How can you say that?  What do you mean 'games'?  I think your definition of
games needs adjusting.  What I see on the clones, and the consoles is what I
call games.  Not the AGA crap we have to put up with.

 JrF> Anyone should have checked it can do chunky without delay on most
 JrF> configs. And, take 2x2 on A1200, here AGA performs better in chunky
 JrF> games than a gfx card would (!) so it doesn't sound like a joke if you
 JrF> say custom chips rule.

Do you actually count that as an advantage???  You mean that AGA can do 2x2
faster than gfx-card because on a gfx-card you would have to plot each pixel
four times to get 2x2?

 JrF> Yes, the low bandwidth does brake performance on fast cpus, but the
 JrF> difference vs. a average gfx card when running a chunky clone is less
 JrF> than most people think. You'd need to compare AGA with a very good
 JrF> gfx-card (above 15mb/sec) to have some fps difference. Anyway, when

Definitely not.  Maybe at 2x2 because most gfx-cards can't do 2x2 'standard',
but then I could always use the 'blitterzoom' function on the gfx-card to get
2x2.  Oh, BTW, FastRAM on my Amiga (60 ns) can only do 10 MB/sec at copying
memory.  I think that should easily beat AGA, even if I have to plot every
pixel 4 times.

 JrF> having spent lotsa $ for the 060, a gfx-card should not be that
 JrF> problem. software maybe is...

replace software for 'games and demos'.

 JrF> So I don't cry for new chipset for games, I cry for the new A1200
 JrF> beeing delivered with some fastmem, even 1mb would help A LOT.

Sigh...

 JrF> Later AGA+ having 10 planes etc, would be a nice thing, yes.

Please not, 10 planes would be fucking slow.  For me planar maxes out at around
6 or 7 bitplanes.  It starts to seriously suck above that compared with Chunky.

 >>  TlM> HIT THE HARDWARE! HIT THE HARDWARE! HIT THE HARDWARE! HIT THE
 >>  TlM> HARDWARE!

 >> Spoken like a true retired C-64 coder.

 JrF> well... When cleverly using OS routines, you also hit the hardware, you
 JrF> invoke efficient pokes. Poking blitter is even called legal by Michael
 JrF> ;) (after a  check)

Poking the blitter even after a check should be avoided as much as possible
IMO.  I'd hate to see software fail because they say "can't find the old
terribly slow Amiga blitter which is the only blitter I know how to poke
directly".

 JrF> And some things are not covered by current OS  ($102 change each
 JrF> scanline), so you need own copperlists (OS user coperlists allow no
 JrF> horiz cwait above x=222...). Just make sure the user works on
 JrF> AGA&PAL/NTSC.

Copper will die anyway.  Look at gfx-cards on Amiga today, that's what the
future is going to look like.  No Copper, no hardware to poke (that you would
now about), Chunky and Planar support only to about 4 bitplanes.  You might as
well get used to it.

 >> Taking a better look at Chunky before dumping it like that might give you
 >> a better perspective as to why some people actually think Chunky is often
 >> better than Planar.  Chunky is used by the clones, that's no reason
 >> however to deny

 JrF> I don't like those "doom got no gameplay we need no chunky" posts. 99%
 JrF> of those posters just tell (think?) that way because there is no real
 JrF> clone on the Ami, and mostly those people don't know that chunky is not
 JrF> the problem, like the original poster.

Oh, but Chunky definitely is part of the problem.  I mean, a good 1x1 convertor
(I don't care for 2x2 or other crap people have come up with to create inferior
displays on Amiga) takes 30-40% on Amiga for a DOOM-clone.  Part of that is of
course caused by the slow ChipRAM, but that 30-40% does not include the
accesses to the FastRAM buffer.  It is just a fact that a DOOM clone on Amiga
could be 30-40% faster with even some of the worst Chunky-cards available now.

 JrF> they would talk different if there was a clones, and building your
 JrF> oppinion in that subjective way is lame.

You forget that you still need a 68040 atleast to do DOOM even if you had a
super-fast Chunky card.  That's why there is no clone, the C2P problem only
makes it worse though, on Amiga you'd require a 68060 to do fast DOOM (TextDemo
runs only 15-20 FPS on a 68060/50, 320x240x8 1x1, floors, walls, ceiling, quite
depressing).

 JrF> I LOVE DOOM. Don't tell me about gameplay, you can do other games with
 JrF> the same engine, that's not the topic.
 JrF> At least I love 3D mapping engines, and I won't change my mind just
 JrF> because there is still no real clone.

See above, you will never see a fast DOOM clone, ChipRAM combined with planar
just screws everything up (1x1 of course and full-screen).

 JrF> Instead I measured fps and had to find out that there are  _wolf_
 JrF> clones that are not much faster than Johns good old Texdemo57, which
 JrF> does realdoom. What about a new version, John :) If I may tell my
 JrF> wishes, give me blitter assisted 2x2 and possibilty to switch to
 JrF> non-shaded 16cyle 020 inner loop or even that 32x32 fake for the floor
 JrF> :)

Never.  2x2 is not DOOM, it just makes things unplayable and lame.  Blitter
assisting is also too limited to be of good use.

Your right about the Wolf clones though, NeMac4 seems slower than TextDemo on
my machine at same res.

 JrF> I'm fed up with 1/2 speed clones. Well, maybe ID soft really has some
 JrF> programmers that know how to map and how to bsp.

BSP is easy, and I know exactly how DOOM works now.  My problem at the moment
is that I want the perfect DOOM engine.  TextDemo currently uses a non-perfect
routine which
-works-, yes, but it is not optimal.  It uses a huge table to store information
during mapping but the table isn't needed at all if I rewrote the engine.

In short a DOOM engine should be done like this (there are other ways of doing
a DOOM engine using only horizontal and vertical polygons (probably the way
AB3d does it) but this is how DOOM does it (I'm very sure of it as my own
engine matches the DOOM engine very well when it comes to 'side-effects' and
things which it can and can't do):

 - Ask the BSP tree routine to give you the closest wall to the player.

 - Check if this wall is visible by comparing it with the field of
   vision.  Also check which side is facing the player (but do not
   discard the wall if it faces away from the player).

 - Now process this single wall.  It is best to rotate the wall first
   (if you hadn't done that already above).  Now you can calc all the
   intersection points of the wall with the 320 possible rays.

 - Process each intersection in turn directly after you found it (this
   is TextDemo's mistake, it stores all the points in a HUGE table).
   Find out the distance of each wall-column to the player's baseline
   (if you rotated the wall this is simply the X or Y coordinate).

 - Draw the wall-column, and store the top and bottom edge of the wall
   column in a table with 4 entries for each column on screen.  There
   are 2 entries to keep track of the ceiling, and 2 entries to keep
   track of the floors.  They keep track of the highest and lowest
   coordinates where walls were drawn at.  If the wall faces away
   from the player then don't draw it, but you still store the lowest
   and highest coordinates of the wall into the table (needed to draw
   floors and ceilings properly).  The entries you modify depend on the
   kind of wall you draw.  There are 3 types of walls, a wall which is
   only part of the ceiling (it connects 2 ceilings with each other), a wall
   which is part of a floor and a ceiling (ie, it connects a floor and a
   ceiling) and a wall which is only part of the floor.

 - After having finished drawing this single wall you immediately draw
   the floor and ceiling above and below it (TextDemo doesn't do that
   either, it draws ALL walls first, and then draws floors and ceilings).

 - You know draw the floor and ceiling below and above the wall you just
   drew using the table.  Depending on how wide the wall is this can
   be just a very small vertical strip of floor or ceiling you need to
   draw.  The advantage however is that you don't need a huge table to
   keep track of the start/end Y points of all the walls.  You need to
   use a special "Vertical-strips"-to-"Horizontal-strips" convertor
   which I created for TextDemo to be able to map floors and ceilings
   horizontally.

 - NOW you process the next wall, by again asking the BSP tree for
   the next closest wall (go to step 1).

The routine stops drawing as soon as you've a 'inpenatrable' wall-column at
each of the 320 columns on screen (you can use a simple counter to keep track
of this).  An inpenatrable wall is a wall which is connected directly to the
floor and ceiling (so the wall is not part of the floor alone, or the ceiling
alone).

I don't suspect to see a huge speed-up in TextDemo when I make this change but
it may well be faster.  The big problem right now with TextDemo that the table
it uses to store all the walls is never big enough.  It depends on how the
level is created.  When you stand in front of a 20 step staircase the table
would need to be 20 layers deep (which it is at the moment).  A longer
staircase with more steps would however make things go seriously wrong as the
table overflows.  The table solution therefore is never adequate and I need to
remove it.  This involves completely rewriting the engine though :-(

Grtz John

-----------------------------------------------------------------------
 [e-mail]   TextDemo/FastView/Etc... development
-----------------------------------------------------------------------
-- Via Xenolink 1.981, XenolinkUUCP 1.1